Communicating Options to a Sub-make

Contents|Index|Previous|Next
Communicating options to a sub-make

Flags such as -s and -k are passed automatically to the sub-make through the variable, MAKEFLAGS. This variable is set up automatically by make to contain the flag letters that make received. Thus, if you do make -ks then MAKEFLAGS gets the value ks.

As a consequence, every sub-make gets a value for MAKEFLAGS in its environment. In response, it takes the flags from that value and processes them as if they had been given as arguments. See Summary of options.

Likewise variables defined on the command line are passed to the sub-make through MAKEFLAGS. Words in the value of MAKEFLAGS that contain =, make treats as variable definitions just as if they appeared on the command line. See Overriding variables.

The options -C, -f, -o, and -W are not put into MAKEFLAGS; these options are not passed down.

The -j option is a special case (see Parallel execution). If you set it to some numeric value, -j 1 is always put into MAKEFLAGS instead of the value you specified. This is because if the -j option was passed down to sub-makes, you would get many more jobs running in parallel than you asked for. If you give -j with no numeric argument, meaning to run as many jobs as possible in parallel, this is passed down, since multiple infinities are no more than one. If you do not want to pass the other flags down, you must change the value of MAKEFLAGS, like the following example shows.

MAKEFLAGS=
subsystem:
cd subdir; $(MAKE)

Alternately, use the following examples input.

subsystem:
cd subdir; $(MAKE) MAKEFLAGS=

The command line variable definitions really appear in the variable, MAKEOVERRIDES, and MAKEFLAGS contains a reference to this variable. If you do want to pass flags down normally, but dont want to pass down the command line variable definitions, you can reset MAKEOVERRIDES to empty, like MAKEOVERRIDES =.

This is not usually useful to do. However, some systems have a small fixed limit on the size of the environment, and putting so much information in into the value of MAKEFLAGS can exceed it. If you see the error message Arg list too long, this may be the problem. (For strict compliance with POSIX.2, changing MAKEOVERRIDES does not affect MAKEFLAGS if the special target .POSIX appears in the makefile. You probably do not care about this.)

A similar variable MFLAGS exists also, for historical compatibility. It has the same value as MAKEFLAGS except that it does not contain the command line variable definitions, and it always begins with a hyphen unless it is empty (MAKEFLAGS begins with a hyphen only when it begins with an option that has no single-letter version, such as --warn-undefined-variables). MFLAGS was traditionally used explicitly in the recursive make command, like the following.

subsystem:
cd subdir; $(MAKE) $(MFLAGS)

Now MAKEFLAGS makes this usage redundant. If you want your makefiles to be compatible with old make programs, use this technique; it will work fine with more modern make versions too.

The MAKEFLAGS variable can also be useful if you want to have certain options, such as -k (see Summary of options), set each time you run make. You simply put a value for MAKEFLAGS in your environment. You can also set MAKEFLAGS in a makefile, to specify additional flags that should also be in effect for that makefile. (Note that you cannot use MFLAGS this way. That variable is set only for compatibility; make does not interpret a value you set for it in any way.)

When make interprets the value of MAKEFLAGS (either from the environment or from a makefile), it first prepends a hyphen if the value does not already begin with one. Then it chops the value into words separated by blanks, and parses these words as if they were options given on the command line (except that -C, -f, -h, -o, -W, and their long-named versions are ignored; and there is no error for an invalid option).

If you do put MAKEFLAGS in your environment, you should be sure not to include any options that will drastically affect the actions of make and undermine the purpose of makefiles and of make itself. For instance, the -t, -n, and -q options, if put in one of these variables, could have disastrous consequences and would certainly have at least surprising and probably annoying effects.

Top|Contents|Index|Previous|Next